The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
Some printing devices are configured with a feature known as “locked printing” to provide control over the printing of electronic documents. When a printing device is configured with a locked printing feature and print data is sent to the printing device, a printed version of an electronic document reflected in the print data is not generated until a password is verified at the printing device. Typically a user enters a password through an operation panel on the printing device. The printing device verifies the password and if the password is successfully verified, allows a printed version of the electronic document reflected in the print data to be generated, i.e., printed.
The locked printing feature may entail encrypting the print data, compressing the print data, and storing encrypted and compressed print data in non-volatile media. Implementing this feature in a platform-independent programming language, such as the Java programming language (herein “Java”), causes the steps of encrypting, compressing, decompressing, and decrypting to be performed relatively slow compared to implementing the locked printing feature in a platform-dependent programming language, such as the C programming language (herein “C”). However, there are sufficient reasons for implementing the user interface (e.g., on the printing device), which accepts user input, in a platform-independent programming language, such as Java. Therefore, there is a need to combine the benefits of implementing the locked printing feature in relatively fast programming language with the benefits of implementing the user interface in a program-independent programming language.